System Integrity Considerations

Screen mapping actions that cause a host system to be updated should be acknowledged by the host before another command is sent. The host interface is designed to automatically accommodate for this as much as possible. The script or macro waits for the host to not be busy before reading from or writing to the host screen. In a host-busy condition (input inhibited), The server will wait for the timeout period specified in the settings for the condition to clear. However, screen mapping VBA extensions should be incorporated to provide ways of acknowledging successful actions.  For instance, the following commands may be used to provide programmer control over host sessions:

SM.WaitForText – This function looks for a unique text string on the screen for a specified amount of time. If the text is found, it returns True, otherwise, it times out with a value of False.

SM.WaitForCursor – This function waits until the screen input cursor stops at the desired location for a specified amount of time. If the cursor stops at the desired location, it returns True, otherwise, it times out with a value of False.

SM.WaitForScreen – This function looks for the desired screen identifier for a specified amount of time. If the application is in the correct screen, it returns True, otherwise, it times out with a value of False.

SM.WaitForHost – This function is designed for vt220 connections. As the vt220 protocol does not typically include input inhibit conditions, this function will return True once the host responds to the previous action command, otherwise, it will time out with a value of False.

SM.CallMacro – This function has a “Queue-Offline” argument, which, if enabled, will store the transaction if the host is offline. These “store-and-forward” transactions will be processed automatically once the host connection is re-established.

Note: the ‘SM.WaitFor…’ commands are primarily useful (and perhaps required) for VT hosts.

See Screen Mapping Extensions section for more information.